Date: Wed, 30 Mar 94 04:30:23 PST 

From: Ham-Digital Mailing List and Newsgroup <ham-digital@ucsd.edu> 
Errors-To: Ham-Digital-Errors@UCSD.Edu 

Reply-To: Ham-Digital@UCSD.Edu 

Precedence: Bulk 

Subject: Ham-Digital Digest V94 #87 

To: Ham-Digital 


Ham-Digital Digest Wed, 30 Mar 94 Volume 94 : Issue’ 87 


Today's Topics: 
DGMSK? 
HF Throughput Revisited 
mailgateway Packet Radio <--> Internet 
Newbie Q: obtaining IP address 
NTS traffic on packet (2 msgs) 


Send Replies or notes for publication to: <Ham-Digital@UCSD.Edu> 
Send subscription requests to: <Ham-Digital-REQUEST@UCSD.Edu> 
Problems you can't solve otherwise to brian@ucsd.edu. 


Archives of past issues of the Ham-Digital Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital". 


We trust that readers are intelligent enough to realize that all text 
herein consists of personal comments and does not represent the official 
policies or positions of any party. Your mileage may vary. So there. 


Date: 28 Mar 94 18:16:00 GMT 


From: dog.ee.lbl.gov!agate! library.ucla.edu!news.mic.ucla.edu!unixg.ubc.ca! 


nntp.cs.ubc.ca!utcsri! newsflash. concordia.ca!canopus.cc.umanitoba.ca! 
mona.muug.mb.ca!mwcsinc!bill.@ihnp4.ucsd.edu 

Subject: DGMSK? 

To: ham-digital@ucsd.edu 


o@TO :dreamer@lhaven.UUmh.Ab.Ca N 
-> What kinds of high speed packet data are allowed? Are there 

-> regulations on what kind of data modulation is employed for packet 
-> operation? 


-> A whole bunch of old 9600bps data radios have become 

-> available...... they do something like DGMSK or letters to that 

-> effect....and immediately its said that's illegal. because its not 
-> AFSK...and the units don't do AX.25. 


Rubbish. Read RIC 24 and RIC 25. You can't use a secret code - any 


coding done to improve information handling is OK, if you're using 
something unusual you should be prepared to explain how it works to 
the local DOC. You must faithfully observe the bandwidth limitiations 
in the table. You must of course not use frequencies below 50 MHZ if 
you don't know how to send Morse. Aside from that, there is no 
restriction on what you can use ( in Canada) for amateur radio data. 
The US rules are written more for the benefit of lawyers and hams but 
their problems need not concern you; and from what I've read the only 
restrictions they have is that 3rd party traffic handled by an 
unattended station must use AX.25 - they also have some baud rate 
restrictions. Local rules only, don't apply to you, have fun. Get 
a G3RUH or KING modem from TAPR, couple of old radios, and leave 1200 
in the dust. 

Bill 

vedstw 


Muddy Waters Computer Society Inc. Winnipeg, Manitoba, Canada 
(204) 943-6507,08,09 (204)942-0227 (204)956-4997 (all nodes USR 16.8K D/S) 


Date: 29 Mar 94 18:32:55 GMT 

From: agate! howland.reston.ans.net!pipex!sunic!psinntp!psinntp!arrl.org! 
jbloom@ucbvax.berkeley.edu 

Subject: HF Throughput Revisited 

To: ham-digital@ucsd.edu 


Beek Whiting (Rick_Whiting@ATK.COM) wrote: 

: surprised CLOVER did not do better.] Based on this and other 

: published data, the throughput (CPS) for various protocols on HF 

: would appear to line up as follows: AX.25 Packet 4, AMTOR ARQ 5, 
RTTY 6, PacTOR 9-10, CLOVER 16, and G-TOR 24. 


: By the way, I don't think the Kantronics KAM used in Westhuizen's 
: tests implemented hardware ADC Memory ARQ. Furthermore, the 


No, it doesn't. But it's debatable how much difference that makes. 
Kantronics says they haven't been able to measure a difference, 
although they also say their testing hasn't been extensive on this 
point. 


: various throughput data cited above were not taken by the same 
: experimenters under similar conditions, etc. 


Right, which makes the comparison very much apples and oranges. Given 
the massive variations in HF conditions fram band to band, location to 
location, season to season and, often, minute to minute, you need a lot 


more data than this to make any useful comparisons! Plus, three of 
these protocols are adaptive. (Clover is bit-rate adaptive, PACTOR and 
G-TOR are bit- and symbol-rate adaptive.) Thus it is crucial to factor 
in the channel conditions, since throughput will vary, probably non- 
monotonically, with channel degradations of various types and 
combinations. That way, you can determine which protocols favor which 
propagation conditions, and by how much. Or you can factor xoutx the 
channel conditions by taking a lot of data that span the (reasonable) 
range of channel conditions to get a "figure of merit" for each 
protocol. But since none of that has been done--or published, at any 
rate--the conclusions you can draw from the given data are nonexistant. 


And the term "throughput" itself is a bit slippery here. How do you 
count the characters that RTTY or AMTOR "receive" but which are not the 
characters that were sent? Seems unfair to the protocols that provide 
data integrity to count garbled characters the same. Bottom line: 
comparing error-free protocols with RTTY/AMTOR is comparing not just 
apples and oranges, but two entirely different food groups! 


That said, there is plenty of evidence, both analytical and empirical, 
that suggests that any non-adaptive, non-FEC protocol is going to 
perform worse on HF, in general, than an adaptive protocol with FEC. 
Plus, I suggest that any protocol that allows undetected errors in 
reception is a nonstarter for serious HF communications in the 1990s. 
(Although they are fun to play with, and I certainly don't discount 
that.) Taking those two factors together, I suggest that the protocols 
whose throughput is of interest are PACTOR, CLOVER and G-TOR, in no 
particular order. The others are suitable only for play. 


: Of course, there are many features that differentiate the different 
protocols beside typical throughput, not the least of which is 
: throughput normalized to bandwidth, i.e., CPS per hertz. And the 


Yes, and isn't it interesting that the one with the widest bandwidth 
supports the lowest throughput? (Even though the data above isn't 
particularly useful, I feel confident in saying that any test under 
conditions other than excellent will show AX.25 to be a loser.) 


Jon Bloom KE3Z jbloom@arrl.org 


Date: Mon, 28 Mar 94 06:56:18 MST 

From: ihnp4.ucsd.edu!dog.ee.1lbl.gov!agate!howland.reston.ans.net!cs.utexas.edu! 
asuvax!ennews!stat!david@network.ucsd.edu 

Subject: mailgateway Packet Radio <--> Internet 

To: ham-digital@ucsd.edu 


> > I have read in the newsgroup rec.radio... 
> > in Amerika you have a mailgateway between Packet-Radio 
> > and Internet. 


How to Use the WB7TPY 
Packet <-> Internet Gateway 

First, some brief operational notes: 
(1) Messages must not contain any foul language, or commercial purpose. 
(2) Messages can only be sent to countries that the United States has 

a third-party agreement. All others will be destroyed. 
(3) Messages from the internet should be less then 5K in length. 

No files should be sent. 
(4) If you have questions, please do not hesitate to contact me either on 


packet radio: WB7TPY@WB7TPY.AZ.USA.NA -Or- 
Internet : david@stat.com 


(5) Have fun. Use the gateway as much as you like. That is what it is 
there for. 


Send mail to the internet address of: 
gate@wb7tpy.ampr.org 


The first line of text must contain a full packet address, preceded with the 
word "Packet: " 


For example, mail to my packet address, would have the first line of text; 


Packet: wb7tpy@wb7tpy.az.usa.na 


xx NOTE: this line MUST be left justified. 


Send as private mail (never a bulletin) to the packet address of: 


gate@wb7tpy.az.usa.na 


The first line of text must contain a full domained internet address, 
proceeded with the word "Internet:" 


For example, mail to my internet address, would have the first line of text; 


Internet: david@stat.com 


Editor, HICNet Medical Newsletter 
Internet: david@stat.com FAX: +1 (602) 451-1165 
Bitnet : ATWIH@ASUACAD 


Date: 30 Mar 94 00:40:39 GMT 

From: dog.ee.lbl.gov!agate!msuinfo! cravitma@ucbvax.berkeley.edu 
Subject: Newbie Q: obtaining IP address 

To: ham-digital@ucsd.edu 


Apologies for the Newbie question, but... 


I am thinking about trying to set up NOS on the Club machine here at 
MSU. I think I can figure out how to get the software set up, but I 
have three questions: 


1. Where do I get an IP address for our machine? 

2. Where do I get a host file so that our machine knows about 
others on the net? 

3. How do I propagate our IP address and hostname so that other 
systems know about it and where it is on the net? 


Thanks for any help. Responses via email are fine. 


/Matthew 

Matthew Cravit, N9OVWG | All opinions expressed here are 
Michigan State University | my own. I don't speak for MSU 
E-Mail: cravitma@cps.msu.ed | and they don't speak for me. 


GO/CS -d+@ -p+ c++ !1 u+(++) e+(*) s/+ n+(---) h+ f+ !9 w+(4+t++) t++@ r(+) y? 


Date: Tue, 29 Mar 1994 15:01:46 GMT 


From: ihnp4.ucsd.edu!dog.ee.1lbl.gov!agate!howland.reston.ans.net! 
europa.eng.gtefsd.com!emory!nntp.msstate.edu!olivea!news.bu.edu!att-in!att-out! 
cbnewsh! ostroy@network.ucsd.edu 

Subject: NTS traffic on packet 

To: ham-digital@ucsd.edu 


Here's my two cents on a subject near and dear to my heart. 


Tod|> I am advised by local packet network managers and the local NTS 
Tod|> representatives that NTS traffic fares poorly on the packet network. The 
Tod|> problem is one of "culture" 
Tod|> The traffic culture was built around HF operations - originaly spark, then 
Tod|> cw , then voice and cw. When digital modes appeared, particularly AMTOR, 
Tod|> the NTS began to incoporate that mode for traffic. The traffic culture is 
Tod|> based upon one person handing traffic to another and the second person 
Tod|> agreeing to forward or deliver the traffic. The Q-signals reflect this 
PAV AVAVAVAVATATAVATA TATA TATA TATA TATA TATATATATATATATATATATATAS 

That's the key. in the old NTS, the recipient, by virtue of taking traffic, 

agrees to "forward or deliver" . A destination bbs, by contrast, has no 

obligation to forward or deliver. It simply waits for someone to "come 

and get it". It could wait forever. 


Hank>It is not "sent to a callsign", nor is it "placed in a file", it is sent 
Hank>to a zipcode, and is then picked up and delivered by xanyx NTS person who 
PAV AVAVAVAVATATAVATATATATATATATATATATATATATATAS 
picked up by who? There are not that many people interested in picking 
up messages off a bbs and delivering them to the general public. 


Hank>wishes to do so. If any NTS message is "stuck" at some BBS, the problem 
Hank>lies with the NTS organization. One needs to think of the packet BBS system 
Hank>just like any other transport system. It needs to be serviced. 


Very true, but in reality, both Tod and Hank have said the same thing. 
Although the mechanism is there to move traffic on packet, the culture 
is not. 


Tod|> Most BBS operators implore those who check in to look at the accumulation 
Tod|> of NTS messages and accept one or more that they are willing to relay or 
Tod|> deliver. The problem is that there is not a habit pattern or culture 

Tod|> that has grown up within the packet community to accept such activity as 
Tod|> something of interest. In some cases, the persons checking in may not have 
Tod|> HF priviledges that permit them to off-load the messages to the local 
Tod|> traffic nets. 


Hank>This is an NTS problem, not a packet network problem. 

Hank>Why would one offload NTS traffic onto HF? This is exactly what the BBS 
Hank>system is good at; moving bunches of traffic from point A to point B 
Hank>without error for any user who wishes to use it. 


have 


In my area, the vast majority of traffic which is removed from the bbs' 
is brought to a 2meter or 80/75meter net for delivery. This is because 
there are just not enough interested message deliverers to cover an 
entire section or state. 


Hank, the problem is that messages are not sent to a specific "user" at 

the receiving end. They are broadcast. Messages sent to some destinations 
about as much chance for success as a CQ on 10 meters at 

the sunspot nadir. In the old NTS, all messages are handed to a specific 
user, the next person in the pipeline, until the last person is reached. 


Tod|> In summary, this is an interesting situation which perhaps offers an 

Tod|> opportunity for public service. If such a culture were developed, it would 
Tod|> be in place ready to go in the event of an emergency. Regrettably, to date 
Tod|> the right ingredients have not come together. 


Hank>The opportunity has been there for ten years now. The BBS system has 
Hank>worked in the same way with respect to NTS traffic since at least late 
Hank>1984. NTS has failed totally to take advantage of the resource available to 
Hank>them, at least in most areas of the country. NTS must understand that the 
Hank>average BBS sysop is xnotx part of NTS, and has *no*x particular interest in 
Hank>NTS messages per se. These messages are treated like any other traffic; 
Hank>moved to their destination by the quickest method possible. They key thing 
Hank>that NTS *xmust* do to make use of the network is to assign liason staff to 


TAVAYAVAVATAVAVALATAVATATAS 


a great idea ...IF you can find enough interested people. 


Hank>the network. This has been done since 1986 in New England, and it works 
Hank>fairly well. Speaking for the area in which I now live, NTS folks are 


Frankly, if your sole traffic-handling activity is just picking messages 
off a bbs that you can deliver toll-free, you are going to get bored 

real quickly. The NTS "culture" has been built for years around 
participation in the pipeline, as an integral part of it. The packet bbs 
system has taken away the pipeline from the NTS'er and left nothing but 
simple unchallenging user interfaces at either end. No wonder NTS'ers are 
not interested. It's going to take a long time to develop a culture 

of message deliverers, as opposed to traffic network operators. 


(By the way, I participate in both facets of the hobby, lest you 
suspect bias.) 


Dan Ostroy - K2UL - 
AT&T Bell Labs, Holmdel, NJ USA 908-949-5922 ostroy@cbnewsh.att.com 


Date: Tue, 29 Mar 94 19:06:51 GMT 

From: netcomsv!netcomsv!skyld! jangus@decwrl.dec.com 
Subject: NTS traffic on packet 

To: ham-digital@ucsd.edu 


In article <2n9j6k$db9@hp-col.col.hp.com> jms@col.hp.com writes: 
This reply is directed to anyone who is taking part in this discussion. 


The problems I see with the end delivery of packet nts traffic are: 


> 

> 

> 

> 

> 2. Some BBS systems do not allow a person to 'kill' a message once 
> it's been read for delivery. I WILL NOT deliver traffic from 

> such a board as it's embarrassing to attempt delivery when 

> someone else has already done so. 

JNOS (wg7j main author) allows anyone to kill mail in an area with NTS 
prefacing it. (Areas as opposed to listing by topic) 


So there are three catagories of areas now on my system, private (you 
have to be that person to read/kill) public (anyone can read, but sysop 
only to kill) and NTS (anyone can read and then kill). 


So, can present BBs software be configured to forward nts traffic 

to a given station, preferably re-address it to that Amateur's 

call sign so they know there is messages waiting? Can it be set 

up to send it to a different person each day, with maybe a different 
person on odd or even weeks (don't want to leave out anyone who 
wants to play)? 


VVVVV V 


A simple entry in the alias file will forward to whomever. so if I 
alias 90505 to kf6pu@wb6ymh.#soca first the alias file redirects it 
to kf6pu, the my rewrite file queues it up for delivery to the wb6ymh 
bbs. 


> BTW, thanks to all the BBS sysops out there that keep the boards 
> up and running. I know it's a big job and a lot of work. 


It is, but it is one of the ways to return something to the hobby. 
I'll leave it to some of our other members to do the take-take-take 
routine. 


73 es GM from Jeff 


Amateur: WA6FWI@WA6FWI.#SOCA.CA.USA.NOAM | "You have a flair for adding 
Internet: jangus@skyld.grendel.com | a fanciful dimension to any 
US Mail: PO Box 4425 Carson, CA 90749 | story." 


Phone: 1 (310) 324-6080 Peking Noodle Co. 


Date: 29 Mar 94 16:26:10 GMT 

From: agate! howland.reston.ans.net!europa.eng.gtefsd.com!emory!wad4mei! ke4zv! 
gary@ucbvax.berkeley.edu 

To: ham-digital@ucsd.edu 


References <nilistCnDtGM.4r6@netcom.com>, <CnEF6L.181@world.std.com>, 
<gganderson.321.0@augustana.edu> 

Reply-To : gary@ke4zv.atl.ga.us (Gary Coffman) 

Subject : Re: NTS Only BBS? (was Re: [REPOST] NTS Traffic on Packet) 


In article <gganderson.321.0@augustana.edu> gganderson@augustana.edu (Kevin 
Anderson -7325) writes: 

>(2) I how much time, effort, and cost is involved in running a BBS? 

> 

>I ask not to point any fingers, but because I can't fathom what 

>the costs would be. I can think of there being the expense for 

>a good antenna, a reasonable 2m rig (50 watts?), a reasonably 

>fast computer (486 of some flavor) with a decent size hard disk, 


Gad! What do you think a packet BBS is, a major internet node on 
T1 trunks? An original IBM AT (8 MHz 286 with a 20 Mb hard disk) 
is beaucoup plenty computer to deal with the 1200 baud half duplex 
demands of VHF packet, or the 300 baud demands of HF packet. The 
main thing the computer needs is xpatiencex, and machines, even 
old machines, are good at that. What you do need is good radio 
equipment, excellent antennas, and in the case of VHF a very 

good high site for user access and forwarding. Likely you'll 

have several radios on several frequencies for user traffic 

and BBS to BBS forwarding. 


>that this power-hungry computer (400 VA watts?) would be running 
>24 hours a day, your time and effort in seeing that the computer 
>and radio keep running. I suspect MUCH IS already being given 
>by BBS operators as a service, but I'm just curious of the 
>accounting. 


The major cost of operating a full service BBS is *timex. It takes 
hours a day to manage the system and deal with naive users. There 
are routing databases to maintain, rewrite files to update, manual 
rerouting of naive user Email attempts, etc, etc, etc. Many Sysops 
keep spare radios and antennas, and spare computers, in order to 
maintain service in the event of downtime due to equipment failure. 
The wear and tear on the radio equipment is considerably higher 
than what most amateur grade equipment was designed to withstand. 


Since it's 24 hr operation, good lightning protection is a must. 


Gary 

Gary Coffman KE4ZV 
Destructive Testing Systems 
534 Shannon Way 
Lawrenceville, GA 30244 


You make it, 
we break it. 
Guaranteed! 


| gatech!wa4mei! ke4zv! gary 
| uunet!rsiatl!ke4zv! gary 
| emory!kd4nc!ke4zv! gary 

| 


Date: Mon, 28 Mar 1994 17:17:42 GMT 

From: ihnp4.ucsd.edu!dog.ee.1lbl.gov!agate!howland.reston.ans.net! 
vixen.cso.uiuc.edu!sdd.hp.com!portal.com! portal! combdyn! lawrence@network.ucsd.edu 
To: ham-digital@ucsd.edu 


References <1994Mar23 .180631.11120@mnemosyne.cs.du.edu>, 
<Cn8sEJ.7nL@world.std.com>, <1994Mar26.183922.28611@mnemosyne.cs.du.edu> 
Subject : Re: KPC-3 and TCPIP 


In article <1994Mar26.183922.28611@mnemosyne.cs.du.edu> nburnett@nyx10.cs.du.edu 
(Nathan C. Burnett - N8MBK) writes: 

>dts@world.std.com (Daniel T Senie) writes: 

> 

> 

>>Could you elaborate on this last comment? Obviously the KPC-3 is 1200 only, 
>>but it has software (open squelch) DCD available (just issue a command) and 
>>has KISS mode. Did you experience problems with either of these things? 

> 

>1Yes the KPC-3 does have KISS mode however I prefer to run a KISS only EPROM 
>so I don't have to put it in KISS everytime I want to use it. Also the DCD 
>detection provided by the TAPR DCD mod is IMHO far superior to that of the 
>KPC-3's software DCD. 

> 

Hmm, when I had the KPC-3 on my system....I put it into KISS mode, and left 
it that way....never had to tell it to go into KISS mode again during use. 


I'm now running a DRSI DPK-2 and a AEA PK88, both with the normal ROMs...I 
put them into KISS using a terminal...and I have never taken them out of KISS. 


I can't comment on the superiority of the TAPR DCD mod to the software DCD, 

I ordered one a few weeks ago, and it hasn't arrived yet. But, I'll say the 
software DCD is better than nothing. The squelch on one radio likes to walk... 
the other day it tightened up so I couldn't hear anything..... so the system 
just kept polling every second messing up the network. The week before, the 
squelch opened up and my system couldn't transmit...... 


WORK: lawrence@combdyn.com | PHONE 403 529 2162 | FAX 529 2516 | VE6LKC 
HOME: dreamer@lhaven.uumh.ab.ca | 403 526 6019 | 529 5102 | VE6PAQ 


Praxis BBS - 529 1610 | CYSNET BBS - 526 4304 | Lunatic Haven BBS - 526 6957 


disclamer = (working_for && !representing) + (Combustion Dynamics Ltd.); 


End of Ham-Digital Digest V94 #87 
KKKKKKKKKKKKKKKKKKKKKEKKKEKRKE KAKA 


